Erhard schrieb:
Hi Carsten,
(wegen der Zertifikatsfehlermeldung im SMTP-Protokoll)
(nach meinem Kenntnisstand sollten A und PTR Einträge jeweils deckungsgleich sein)
MX von abbuc.de:
abbuc.de MX preference = 10, mail exchanger = mail.abbuc.de
abbuc.de MX preference = 20, mail exchanger = smtp5.strotmann.de
mail.abbuc.de internet address = 46.38.233.133
smtp5.strotmann.de internet address = 185.92.221.212
PTR-Abfragen:
Address: 46.38.233.133
Name: smtp3.strotmann.de (hier müßte m.E. mail.abbuc.de stehen)
Address: 185.92.221.212
Name: 185.92.221.212.vultrusercontent.com (hier müßte m.E. smtp5.strotmann.de stehen)
Viele Grüße
Erhard
Diese Rückwärtsabfrage war eine Anti-Spam Funktion in den Anfangzeiten des Internet, als es Funktionen wie SPF, DKIM oder DMARC noch nicht gab. Die sollte heute nicht mehr eingesetzt werden. Benutzt wird diese Funktion beim Senden von Mails. smtp5 sendet keine Mails, und smtp3.strotmann.de sendet als smtp3.strotmann.de, da passt der PTR Record.
Der Rechner "46.38.233.133" hat mehrere Domain-Namen (mail.abbuc.de, smtp3.strotmann.de etc).
Korrekt nach dem RFCs wäre, mehrere PTR Records für die IP-Adresse zu haben. Die (alte) Anti-Spam Software, welche die Rückwärtsauflösungen prüft, ist leider (oft) so schlecht geschrieben, das diese mit RFC konformer Konfiguration nicht klar kommt.
Ich habe entscheiden, das ich Sites welche diese veraltete Technik noch einsetzt, ignoriere. In der Praxis ist das auch kein Problem. Diese Prüfung war nie Teil eines Internet-Standards für E-Mail, sondern eine Ad-Hoc Lösung einzelner Mail-Server-Betreiber. Es war (vor über 20 Jahren) "best practice", ist heute aber nur noch "Cargo Cult".
Das TLS-Zertifikat von smtp3 und smtp5 ist mittels DANE und DNSSEC abgesichert. Daher sollten sendende Mail-Server sowohl CN (Domain-Namen) als auch Gültigkeitsdaten im Zertifikat ignorieren und sich an dem DANE-Record für diese Server orientieren.
Da ist die Mail-Server Software vom sendenden Mail-Server (leicht) veraltet, da sie DANE Records nicht prüft. In der Praxis hat das aber keine Auswirkungen (außer das der Sender den Empfänger nicht korrekt identifiziert), die Mail wird trotz des Zertifikatsfehlers transport-verschlüsselt ausgeliefert.
Ich empfehle mal zu schauen ob es eine neue Version der Mail-Server-Software gibt, welche DANE/DNSSEC unterstützt (DANE ist als RFC jetzt auch schon 12 Jahre alt).
Beste Grüsse
Carsten